Identifying malicious client network applications based on network request characteristics

ABSTRACT

An edge server receives a plurality of requests from a client network application for actions to be performed on a resource that is hosted at an origin server. The edge server determines request attributes of the requests and associates the request attributes with a session identifying the client network application. The edge server generates a confidence value for the client network application based at least on the determined request attributes of the plurality of requests and computed session metrics of the session. When the confidence value indicates that the client network application is malicious, the edge server performs one or more mitigation actions.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/417,367, filed May 29, 2019, which is hereby incorporated byreference.

FIELD

Embodiments of the invention relate to the field of networkcommunications; and more specifically, to identifying malicious clientnetwork applications based on network request characteristics.

BACKGROUND

Internet hosts are concerned with maintaining high security,performance, and reliability of their hosted resources, such aswebsites. As the popularity of a resource increases, so does the amountof network traffic that is directed to the resource. A resource can alsobe targeted by attacks from bots attempting to make a resourceunavailable to legitimate users by flooding a resource with requests,commonly referred to as a distributed denial-of-service (DDoS) attack,or to abuse the functionality of the website (e.g., content scraping,credential stuffing, slow brute force attacking, medium-volume attacksat slow endpoints). Heavy traffic caused by attacking bots can affectthe security, performance and reliability of a resource.

Conventional security solutions typically either fingerprint the useragent by what is included in the request headers or present a challengeto gather additional information for fingerprinting. The fingerprintsignatures are then used to classify traffic. The signatures can takedifferent forms: a specific header order, client IP address, support ofJavaScript, CAPTCHA solution status, and/or a machine learned classifierscore. These signatures may be used in conjunction with traffic volumeto classify a DDoS attack. However, these conventional securitysolutions do not effectively detect and stop attacks that are designedto abuse the functionality of the website.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by referring to the followingdescription and accompanying drawings that are used to illustrateembodiments of the invention. In the drawings:

FIG. 1 illustrates an exemplary system according to some embodimentsdescribed herein;

FIG. 2 is a flow diagram that illustrates exemplary operations foridentifying malicious client network applications along a request pathbased on request attributes and session metrics according to anembodiment, according to an embodiment;

FIG. 3 is a flow diagram that illustrates exemplary operations foridentifying malicious client network applications by a centralizedserver based on request attributes and session metrics according to anembodiment, according to an embodiment; and

FIG. 4 is a block diagram illustrating a data processing system that canbe used in an embodiment.

DESCRIPTION OF EMBODIMENTS

A server identifies and mitigates attacks that are designed to abuse thefunctionality of a website. A server receives a request from a clientdevice regarding a resource that is hosted at the server. For example,the request may be an HTTP/S GET request method for the resource. Theserver determines one or more request attributes and associates themwith an HTTP session associated with the request. For instance, timinginformation of the request and one or more characteristics of therequest are recorded and associated with its session. The timinginformation includes when the request was received (e.g., date and/ortime). The one or more characteristics of the request include request“Accept”, “Accept-Language” header value, requested resource path,presence of a session cookie, response status code, content type, andcache status (e.g., whether the resource was available in cache or not),etc. A session is typically a collection of multiple requests andresponses of the client network application, and can be identified bythe TCP connection, by a cookie, by an IP address of the client networkapplication, by the pair of the IP address of the client networkapplication and user-agent, or any combination thereof. In someembodiments, a session is an ordered collection of multiple requests andresponses of the client network application. In such embodiments,request-response pairs can be chronologically ordered.

One or more session metrics are computed of the session including one ormore of: the duration of the session, the number of requests received ofthe session, the ratio of the number of failed requests compared to thenumber of successful requests during the session, inter-request gapdistribution (e.g., the amount of time passing from the previous requestto the current request), request content-type distribution,inter-request timings for specific content types (e.g., inter-requesttimings for HTML pages and/or JSON objects, the components of arequested resource [images, javascript files, videos, etc.]), responsecode distribution, and/or HTTP method distribution. One or morezone-wide metrics (of all sessions for a zone over a predetermined time)may also be computed including one or more of: the median duration ofall sessions, the median number of requests per session across allsessions, the number of failed requests compared to the number ofsuccessful requests across all sessions, inter-request gap distributionacross all sessions (e.g., the amount of time passing from one requestto another request during the sessions), request content-typedistribution across the sessions, inter-request timings for specificcontent types across the sessions (e.g., inter-request timings for HTMLpages), response code distribution across the sessions, and/or HTTPmethod distribution across the sessions. The ratios between theper-session metrics the zone-wide metrics may also be computed.

A comparison is made between the current request and/or session withhistorical data analyzed from previous requests and/or sessions todetermine whether a client network application is malicious (e.g., a botthat serves malicious purposes). In an embodiment, the calculated valuesare scored against a previously trained machine learning model todetermine if the client network application is malicious or not. Basedon the analysis of the information of the request and its session, aconfidence value is generated indicating whether the client networkapplication is malicious. When the confidence value indicates that theclient network application is malicious, the server performs one or moremitigation actions. For example, the server can block the request orflag the request. When the confidence value indicates that the clientnetwork application is not malicious, the server processes the requestin its normal way (e.g., where the server is an edge server, the edgeserver may send the request to an origin server hosting a requestedresource). In embodiments where the confidence value is generatedoffline and not on the request path (e.g., computed by a centralizedserver), the server can perform one or more mitigation actions (e.g.,drop the request) in response to receiving a subsequent request from aclient network application that matches a particular IP address and/or afingerprint of a particular client network application.

In conventional security solutions, systems can detect DDoS attacks byidentifying an atypical volume of traffic (e.g., a larger number ofnetwork requests than expected), and mitigate the DDoS attack byblocking certain traffic. Also, other conventional security solutionseither fingerprint the user agent by what is included in the requestheaders or present a challenge to gather additional information forfingerprinting, that can be used in combination with traffic volume toclassify DDoS attack traffic. However, these conventional securitysolutions do not effectively detect and stop attacks that are designedto abuse the functionality of the website.

In contrast, embodiments described herein allow the for the detectionand mitigation of attacks that are designed to abuse the functionalityof the website. Embodiments of the invention provide many technicaladvantages, in addition to addressing the deficiencies of previoussolutions. For example, embodiments of the invention evaluate a streamof requests (or multiple requests) from a session versus looking at justthe volume of traffic. As noted above, conventional security solutionsare designed to detect DDoS attacks. In contrast, by evaluating a streamof requests from a session, embodiments of the invention can detectother types of attacks, such as content scraping and credentialstuffing.

FIG. 1 illustrates an exemplary network architecture that useembodiments described herein. The service illustrated in FIG. 1 includesedge server(s) 120 that are situated between client computing devices110A-I and origin server(s) 130A-N. In one embodiment, edge server(s)120 are reverse proxy servers. In one embodiment, certain networktraffic is received and processed through edge server(s) 120. Forexample, web traffic (e.g., HTTP requests/responses, HTTPSrequests/responses, SPDY requests/responses, HTTP/2 requests, responses,etc.) for domains handled by origin servers 130A-N may be received andprocessed at edge server(s) 120. In one embodiment, domain owners arecustomers of the cloud-based edge service and certain network trafficfor their websites are received and processed at edge server(s) 120.

Client devices 110A-I are computing devices (e.g., laptops,workstations, smartphones, palm tops, mobile phones, tablets, gamingsystems, set top boxes, wearable devices, electronic devices, etc.) thatare capable of transmitting and/or receiving network traffic. Thenetwork traffic may be legitimate network traffic or illegitimatenetwork traffic (e.g., traffic that is part of an attack). Each ofclient devices 110A-I executes client network application 115 that iscapable of transmitting and/or receiving network traffic. For example,client network application 115 may be a web browser or other applicationthat can access network resources (e.g., web pages, images, JSONdocuments, word processing documents, PDF files, movie files, musicfiles, or other computer files). The client network application may be ascripting application or other application that may be participating inan attack. The client network application 115 may be a legitimate clientnetwork application that sends legitimate network traffic or may be amalicious client network application that sends malicious networktraffic (e.g., a bot that is designed to abuse the functionality of thewebsite).

Origin servers 130A-N are computing devices that may serve and/orgenerate network resources (e.g., web pages, images, word processingdocuments, PDF files movie files, music files, or other computer files).Origin server 130A-N may also be another edge server to the server thatserves and/or generates network resources. Although not illustrated inFIG. 1, it should be understood that the network resources of originservers 130A-N may be stored separately from the device that responds tothe requests. Some of origin servers 130A-N may handle multiple domainsthat resolve to edge server(s) 120.

Although not illustrated in FIG. 1, in one embodiment the serviceincludes multiple nodes (referred herein as “edge service nodes”). Eachedge service node may include any of one or more edge servers, one ormore control servers, one or more DNS servers (e.g., one or moreauthoritative name servers), and one or more other pieces of networkingequipment (e.g., one or more routers, switches, hubs, etc.). The edgeservice node may be part of the same physical device or multiplephysical devices. For example, the edge server(s), control server(s),and DNS server(s) may be virtual instances running on the same physicaldevice or may be separate physical devices. Each edge service node maybe part of a data center or a collocation site.

The service may also include control server 125, which may be owned oroperated by the service. In one embodiment, control server 125 providesa set of tools and interfaces for customers (e.g., domain owners) toconfigure security settings of the service. In some embodiments, controlserver 125 may be used to send a command to edge server(s) 120 toperform the classification of requests to identify whether requests arefrom malicious or non-malicious client network applications, asdescribed herein.

In some embodiments, the service includes multiple edge servers that aregeographically distributed. For example, in some embodiments, theservice uses multiple edge service nodes that are geographicallydistributed to decrease the distance between requesting client devicesand content. The authoritative name servers may have a same anycast IPaddress and the edge servers may have a same anycast IP address. As aresult, when a DNS request is made, the network transmits the DNSrequest to the closest authoritative name server (in terms of therouting protocol metrics). That authoritative name server then respondswith one or more IP addresses of one or more edge servers within theedge service node. Accordingly, a visitor will be bound to that edgeserver until the next DNS resolution for the requested hostname(according to the TTL (“time to live”) value as provided by theauthoritative name server). In some embodiments, instead of using ananycast mechanism, embodiments use a geographical load balancer to routetraffic to the nearest edge service node.

To classify the requests to determine a likelihood of whether thetraffic is being received from a non-malicious client networkapplication (e.g., from a human user that is not attacking the website)versus a malicious client network application, the service analyzesrequests received by edge server(s) 120 from client network applications(e.g., client network application 115) operating on client devices(e.g., client devices 110A-I). Edge server(s) 120 includes request-basedbot detection and mitigation module 170 that is configured to receiverequests to access resources hosted by origin server 130A-N. Inaddition, request-based bot detection and mitigation module 170 oncontrol server 125 and/or edge server(s) 120 is further configured toanalyze attributes of the requests and session metrics, determinewhether a client network application is likely malicious based on thedetermined attributes and session metrics, and perform one or moremitigation actions as appropriate.

In one embodiment, request-based bot detection and mitigation module 170determines for each request, one or more request attributes andassociates the request attributes with its session. For example, the oneor more request attributes may include timing information of the requestand one or more characteristics of the request. The timing informationincludes when the request was received (e.g., date and/or time). The oneor more characteristics of the request include response status code,content type, etc. The HTTP session can be identified by the TCPconnection, by a cookie, by an IP address of the client networkapplication, by the pair of the IP address of the client networkapplication and user-agent, or any combination thereof. In anembodiment, a request-based bot detection and mitigation module 170 onthe edge server 120 may determine the request attribute(s) and thesession identifier for each request and transmit that information to therequest-based bot detection and mitigation module 170 on the controlserver 125 for further processing including calculating the confidencevalue offline.

The request-based bot detection and mitigation module 170 computes oneor more session metrics for the session including one or more of: theduration of the session, the number of requests received of the session,the ratio of the number of failed requests compared to the number ofsuccessful requests during the session, inter-request gap distribution(e.g., the amount of time passing from the previous request to thecurrent request), request content-type distribution, inter-requesttimings for specific content types (e.g., inter-request timings for HTMLpages), response code distribution, and/or HTTP method distribution. Therequest-based bot detection and mitigation module 170 also computes oneor more zone-wide metrics (of all sessions for a zone over apredetermined time) including one or more of: the duration of allsessions, the number of requests across all sessions, the number offailed requests compared to the number of successful requests across allsessions, inter-request gap distribution across all sessions (e.g., theamount of time passing from one request to another request during thesessions), request content-type distribution across the sessions,inter-request timings for specific content types across the sessions(e.g., inter-request timings for HTML pages), response code distributionacross the sessions, and/or HTTP method distribution across thesessions. The ratios between the per-session metrics the zone-widemetrics may also be computed.

The request-based bot detection and mitigation module 170 determines,using the request attributes and the session metrics, a likelihood ofwhether the traffic is being received from a legitimate client networkapplication (e.g., from a human user that is not attacking the website)versus a malicious client network application (e.g., an attacking bot).In an embodiment, the calculated values are scored against a previouslytrained machine learning model to determine if the client networkapplication is malicious or not. The machine learning module may producea confidence value indicating whether the client network application issuspected to be malicious.

If it is determined that the client network application is suspected tobe malicious, the request-based bot detection and mitigation module 170performs one or more mitigation actions. For example, the request may bedropped. As another example, a reputation score for the client networkapplication (e.g., as identified through the source IP address of theclient network application) may be lowered that may cause futurerequests from the client network application to be blocked or challenged(e.g., via a CAPTCHA). In some embodiments, edge server 120 creates a“(request label, request confidence %)” tuple as metadata associatedwith the request. In such embodiments, a filter-based firewall canretrieve the metadata associated with the request and block the request.

In one embodiment, request-based bot detection and mitigation module 170performs the above-noted operations on a request in real-time prior tofurther processing (e.g., prior to sending the request to its originserver). In other embodiments, request-based bot detection andmitigation module 170 performs the above-noted operations on a requestasynchronously with sending the request to origin servers 130A-N oroffline after sending the request to origin servers 130A-N.

FIG. 2 is a flow diagram 200 that illustrates exemplary operations foridentifying malicious client network applications along a request pathbased on request attributes and session metrics according to anembodiment. The operations of FIG. 2 will be described with reference tothe exemplary embodiment of FIG. 1. However, it should be understoodthat the operations of FIG. 2 can be performed by embodiments of theinvention other than those discussed with reference to FIG. 1, and theembodiments discussed with reference to FIG. 1 can perform operationsdifferent than those discussed with reference to FIG. 2. The operationsof FIG. 2 are described as being performed by an edge server (e.g., edgeserver 120). However, in some embodiments, the operations are performedby another device (e.g., control server 125, origin servers 130A-N,etc.). In some embodiments, the operations are performed byrequest-based bot detection and mitigation module 170 operating on edgeserver(s) 120, control server 125, or origin servers 130A-N.

At operation 205, an edge server (e.g., one edge server from set of edgeservers 120) receives a plurality of requests from a client networkapplication. In one embodiment, each request in the plurality ofrequests is for an action to be performed on a resource that is hostedat an origin server. For example, edge server 120 receives a pluralityof HTTP “GET” requests to access resources hosted by one or more originservers (e.g., origin servers 130A-N). In one embodiment, each requestis received by edge server 120 as a result of a DNS for the hostnameresolving to an IP address of edge server 120 instead of resolving to anIP address of origin server 130A. For example, a requested resource isan HTML page located at, e.g., www.example.com. In one embodiment, edgeserver 120 receives the request for the resource from client networkapplication 115 (e.g., a browser or other network application) operatingon a client device (e.g., client device 110A). In one embodiment, edgeserver 120 receives the request as part of an HTTP session from clientdevice 110A.

At operation 210, edge server 120 determines one or more requestattributes for each request in the plurality of requests and associatesthe one or more request attributes with a session that identifies theclient network application. For example, edge server 120 determines theone or more request attributes, including timing information of therequest and one or more characteristics of the request. Characteristicsof the request can include an IP address, an order of request headers,whether the request includes a malformed header, etc. The timinginformation can include when the request was received (e.g., date and/ortime). The one or more characteristics of the request include responsestatus code, content type, etc.

Edge server 120 can group the plurality of requests into a session toassociate requests that occur within a period of time and received fromthe same client network application. In one embodiment, edge server 120generates a unique session identifier to uniquely identify requests froma particular client network application.

At operation 215, edge server 120 computes one or more session metricsof the session. In one embodiment, session metrics of the session caninclude information regarding a duration of the session, a number ofrequests made in the session, a number of unique requests made, a numberof unique requests for a specific content-type, and a number of failedand successful requests.

Edge server 120 can determine patterns related to the current requestswithin a session and/or how the current request relates to previousrequests from previous sessions. For example, edge server 120 candetermine an inter-request time gap distribution to determine an amountof time passing between requests for a particular resource or type ofresource. Edge server 120 can also determine an inter-request time forspecific content types to determine an amount of time passing betweenrequests of a specific content type (e.g., HTML pages). Edge server 120can also determine other characteristics, including: a responsecontent-type distribution, a request HTTP method distribution, aresponse cache presence distribution, a number of unique paths accessed,and a number of unique paths access with a specific content type (e.g.,HTML pages).

Edge server 120 can also determine, based on historical request data,whether the current request exhibits attributes of similar previousrequests, or if the current request exhibits abnormal or unexpectedbehavior. In one embodiment, edge server 120 accesses a database or adata structure storing historical request data. In one embodiment, thehistorical request data includes attributes of previous requests andprevious sessions. In one embodiment, the historical request dataincludes data for requests previously analyzed by edge server 120 and/orfor requests previously analyzed by edge servers other than edge server120. In one embodiment, edge server 120 retrieves historical requestdata for previous requests having similar attributes as the currentrequest. For example, edge server 120 can retrieve previous requestshaving a similar request content type, from the same source as thecurrent request (e.g., the same client network application), requestsdirected to the same resources as one or more of the plurality ofrequests, etc. As an example, a shorter amount of time between requeststhan expected based on the historical request data can indicate therequests are part of a malicious action.

In one embodiment, edge server 120 also computes one or more zone-widemetrics (of all sessions for a zone over a predetermined time) todetermine a baseline to compare against the session for the plurality ofrequests received in operation 205. The one or more zone-wide metricsinclude one or more of: the duration of all sessions, the number ofrequests across all sessions, the number of failed requests compared tothe number of successful requests across all sessions, inter-request gapdistribution across all sessions (e.g., the amount of time passing fromone request to another request during the sessions), requestcontent-type distribution across the sessions, inter-request timings forspecific content types across the sessions (e.g., inter-request timingsfor HTML pages), response code distribution across the sessions, and/orHTTP method distribution across the sessions. The ratios between theper-session metrics the zone-wide metrics may also be computed.

In operation 220, edge server 120 generates a confidence value for theclient network application based on the analysis of the determinedattributes of the plurality of requests, and, based on the computedsession metrics of the session. In one embodiment, edge server 120generates the confidence value for the request using a machine learningmodel. In some embodiments, edge server 120 generates the confidencevalue for the request by applying varying weights to the attributes ofthe request and session metrics of the session, and to the historicalrequest data.

Edge server 120 also generates the confidence value by retrievinghistorical request data from a data structure, the historical requestdata including previous request attributes and previous session metricsassociated with previous requests from the client network application.Edge server 120 analyzes the previous request attributes and previoussession metrics associated with previous requests to identify patternsbetween the previous requests and the plurality of requests to generatethe confidence value for the client network application.

In one embodiment, the confidence value indicates whether the requesthas attributes indicating it originates from a malicious client networkapplication or is legitimate network traffic from a non-malicious clientnetwork application, an API, or from a trusted source.

In operation 225, edge server 120 determines whether the confidencevalue indicates the client network application is malicious ornon-malicious. Edge server 120 can compare the confidence value againsta threshold value. The threshold value can be a default value, asystem-defined values, or a user-defined value. When edge server 120determines that the confidence value for the client network applicationindicates the client network application is not malicious, the flowproceeds to operation 230. When edge server 120 determines that theconfidence value for the client network application indicates the clientnetwork application is malicious, the flow proceeds to operation 235.

In operation 230, edge server 120 sends the plurality of requests to theorigin servers (e.g., origin servers 130A-N) when edge server 120determines that the client network application is not malicious (e.g.,there is high confidence that the request is not an attacking bot orillegitimate network traffic). In one embodiment, edge server 120 sendsthe plurality of requests received in operation 205 to the appropriateorigin server(s). In one embodiment, edge server 120 stores therequests, including the attributes of the request and the session in adata structure (e.g., the data structure from which edge server 120previously retrieved historical request data), for use in subsequentanalyses of requests received by edge server 120.

In operation 235, edge server 120 performs one or more mitigationsaction on the request in response to edge server 120 determining thatthe confidence value indicates the client network application ismalicious. In one embodiment, edge server 120 blocks the plurality ofrequests from transmittal to the origin server(s). In some embodiments,edge server 120 modifies a reputation score associated with the clientnetwork application. In such embodiments, when the reputation score isbelow a threshold value, edge server 120 initiates a challenge processin response to requests from the client network application. In someembodiments, edge server 120 creates a “(request label, requestconfidence %)” tuple as metadata associated with the request. In suchembodiments, a filter-based firewall can retrieve the metadataassociated with the request and block the request.

In one embodiment, when the confidence value for the client networkapplication indicates the client network application is malicious, edgeserver 120 also stores the request, including the attributes of therequest and the session in the data structure from which edge server 120previously retrieved historical request data. When storing the requestinformation, edge server 120 can also flag the stored requestinformation to indicate that the request was determined to have a lowconfidence (e.g., indications the request originated from maliciousclient network application) to prevent subsequent requests havingsimilar attributes as the plurality of requests from being sent to theorigin server.

FIG. 3 is a flow diagram 300 that illustrates exemplary operations foridentifying malicious client network applications by a centralizedserver (e.g., “offline” or outside the request path) based on requestattributes and session metrics according to an embodiment. Theoperations of FIG. 3 will be described with reference to the exemplaryembodiment of FIG. 1. However, it should be understood that theoperations of FIG. 3 can be performed by embodiments of the inventionother than those discussed with reference to FIG. 1, and the embodimentsdiscussed with reference to FIG. 3 can perform operations different thanthose discussed with reference to FIG. 3. The operations of FIG. 3 aredescribed as being performed by an edge server (e.g., edge server 120)and a central server (e.g., control server 125).

In operation 305, an edge server (e.g., one edge server from set of edgeservers 120) receives a plurality of requests from a client networkapplication. In one embodiment, each request in the plurality ofrequests is for an action to be performed on a resource that is hostedat an origin server. For example, edge server 120 receives a pluralityof HTTP “GET” requests to access resources hosted by one or more originservers (e.g., origin servers 130A-N). In one embodiment, each requestis received by edge server 120 as a result of a DNS for the hostnameresolving to an IP address of edge server 120 instead of resolving to anIP address of origin server 130A. For example, a requested resource isan HTML page located at, e.g., www.example.com. In one embodiment, edgeserver 120 receives the request for the resource from client networkapplication 115 (e.g., a browser or other network application) operatingon a client device (e.g., client device 110A). In one embodiment, edgeserver 120 receives the request as part of an HTTP session from clientdevice 110A.

In operation 310, edge server 120 determines one or more requestattributes for each request in the plurality of requests and associatesthe one or more request attributes with a session that identifies theclient network application.

In operation 315, edge server 120 sends the determined requestattributes from the plurality of requests to control server 125. In thismanner, control server 125 performs the analysis of the requestattributes outside of the request path.

In embodiments where edge server 120 sends the determined requestattributes from the plurality of requests to control server 125 outsideof the request path, edge server 120 can send the request to theappropriate origin server prior to, concurrently with, or after sendingthe determined request attributes from the plurality of requests tocontrol server 125

In operation 320, control server 125 receives the request attributesfrom edge server 120. In some embodiments, control server 125 receivesrequest attributes from multiple other edge server(s), in addition tothe request attributes from edge server 120.

In operation 325, control server 125 computes one or more sessionmetrics of the session. In one embodiment, session metrics of thesession can include information regarding duration of the session, anumber of requests made in the session, a number of unique requestsmade, a number of unique requests for a specific content-type, and anumber of failed and successful requests. In one embodiment, controlserver 125 computes one or more session metrics of the session in a likemanner as described in operation 215.

In operation 330, control server 125 edge server 120 generates aconfidence value for the client network application based on theanalysis of the determined attributes of the plurality of requests andbased on the computed session metrics of the session. In one embodiment,control server 125 generates the confidence value for the request in alike manner as described in operation 220.

In operation 335, control server 125 determines whether the confidencevalue indicates the client network application is malicious ornon-malicious. In one embodiment, control server 125 determines whetherthe confidence value indicates the client network application ismalicious or non-malicious in a like manner as described in operation225.

In operation 340, control server 125 generates and sends rule for edgeserver 120 to take one or more mitigation actions. In some embodiments,control server 125 sends the rules to multiple other edge server(s), inaddition to the edge server (e.g., edge server 120) from which controlserver 125 received the request attributes.

In response to determining whether the confidence value indicates theclient network application is malicious or non-malicious, control server125 generates and/or modifies rules for handling subsequent requestsfrom the client network application. For example, when the clientnetwork application is determined to be malicious, control server 125can generate or modify rules to block subsequent requests exhibitingsimilar request attributes. In another example, when the client networkapplication is determined to be non-malicious, control server 125 cangenerate or modify rules to transmit subsequent requests exhibitingsimilar request attributes to the appropriate origin server.

In operation 345, edge server 120 receives receive rules from controlserver 125 generated based on the request attributes and session metricsand applies the rules to subsequent requests having similar requestattributes. In one embodiment, where control server 125 determines thatthe client network application is malicious, the rules indicate to edgeserver 120 to perform mitigation actions in response to edge server 120receiving a subsequent plurality of requests similar to the plurality ofrequests received in operation 305. In one embodiment, edge server 120drops subsequent requests received from the client network applicationor presents a challenge (e.g., a CAPTCHA) in response to subsequentrequests from the client network application. In one embodiment, therules instruct edge server 120 to take mitigation actions against allthe traffic for the associated session, e.g., against traffic associatedwith the IP address of client device 110A. Mitigation action can also beapplied based on a client fingerprint pattern (e.g., header order,presence or absence of a specific header or specific header value,etc.).

FIG. 4 is a block diagram illustrating a data processing system that canbe used in an embodiment As illustrated in FIG. 4, the computer system400, which is a form of a data processing system, includes the bus(es)450 which is coupled with the processing system 420, power supply 425,memory 430, and the nonvolatile memory 440 (e.g., a hard drive, flashmemory, Phase-Change Memory (PCM), etc.). In one embodiment, thecomputer system 100 includes a cache 410. The bus(es) 450 may beconnected to each other through various bridges, controllers, and/oradapters as is well known in the art. The processing system 420 mayretrieve instruction(s) from the memory 430 and/or the nonvolatilememory 440 and execute the instructions to perform operations describedherein. The bus 450 interconnects the above components together and alsointerconnects those components to the display controller & displaydevice 470, Input/Output devices 480 (e.g., NIC (Network InterfaceCard), a cursor control (e.g., mouse, touchscreen, touchpad, etc.), akeyboard, etc.), and the optional wireless transceiver(s) 490 (e.g.,Bluetooth, Wi-Fi, Infrared, etc.). In one embodiment, the client device,edger servers, control server, and/or origin servers described hereinmay take the form of the computer system 400.

The techniques shown in the figures can be implemented using code anddata stored and executed on one or more computing devices (e.g., clientdevices, servers, etc.). Such computing devices store and communicate(internally and/or with other computing devices over a network) code anddata using machine-readable media, such as machine-readable storagemedia (e.g., magnetic disks; optical disks; random access memory; readonly memory; flash memory devices; phase-change memory) andmachine-readable communication media (e.g., electrical, optical,acoustical or other form of propagated signals—such as carrier waves,infrared signals, digital signals, etc.). In addition, such computingdevices typically include a set of one or more processors coupled to oneor more other components, such as one or more storage devices, userinput/output devices (e.g., a keyboard, a touchscreen, and/or adisplay), and network connections. The coupling of the set of processorsand other components is typically through one or more busses and bridges(also termed as bus controllers). The storage device and signalscarrying the network traffic respectively represent one or moremachine-readable storage media and machine-readable communication media.Thus, the storage device of a given computing device typically storescode and/or data for execution on the set of one or more processors ofthat computing device. Of course, one or more parts of an embodiment ofthe invention may be implemented using different combinations ofsoftware, firmware, and/or hardware.

In the preceding description, numerous specific details are set forth.However, it is understood that embodiments of the invention may bepracticed without these specific details. In other instances, well-knowncircuits, structures and techniques have not been shown in detail inorder not to obscure the understanding of this description. Those ofordinary skill in the art, with the included descriptions, will be ableto implement appropriate functionality without undue experimentation.

References in the specification to “one embodiment,” “an embodiment,”“an example embodiment,” etc., indicate that the embodiment describedmay include a particular feature, structure, or characteristic, butevery embodiment may not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it is submitted that it is within the knowledge of oneskilled in the art to effect such feature, structure, or characteristicin connection with other embodiments whether or not explicitlydescribed.

In the preceding description and the claims, the terms “coupled” and“connected,” along with their derivatives, may be used. It should beunderstood that these terms are not intended as synonyms for each other.“Coupled” is used to indicate that two or more elements, which may ormay not be in direct physical or electrical contact with each other,co-operate or interact with each other. “Connected” is used to indicatethe establishment of communication between two or more elements that arecoupled with each other.

While the flow diagrams in the figures show a particular order ofoperations performed by certain embodiments of the invention, it shouldbe understood that such order is exemplary (e.g., alternativeembodiments may perform the operations in a different order, combinecertain operations, overlap certain operations, etc.).

While the invention has been described in terms of several embodiments,those skilled in the art will recognize that the invention is notlimited to the embodiments described, can be practiced with modificationand alteration within the spirit and scope of the appended claims. Thedescription is thus to be regarded as illustrative instead of limiting.

What is claimed is:
 1. A method, comprising: receiving a plurality ofrequests from a client network application, each request in theplurality of requests for an action to be performed on a resource thatis hosted at an origin server; for each request in the plurality ofrequests, determining one or more request attributes of the request andassociating the one or more request attributes of the request with asession that identifies the client network application; computing one ormore session metrics of the session; generating a confidence value forthe client network application based at least on the determined requestattributes of the plurality of requests and the computed session metricsof the session; determining that the confidence value indicates that theclient network application is malicious; in response to determining thatthe confidence value indicates that the client network application ismalicious, performing one or more mitigation actions.
 2. The method ofclaim 1, wherein generating the confidence value for the client networkapplication comprises: retrieving historical request data from a datastructure, the historical request data including previous requestattributes of previous requests from the client network application; andanalyzing the previous request attributes of the previous requests toidentify patterns between the previous requests and the plurality ofrequests.
 3. The method of claim 1, wherein performing the one or moremitigation actions comprises: modifying a reputation score associatedwith the client network application; and initiating a challenge processin response to a subsequent request from the client network application.4. The method of claim 1, wherein performing the one or more mitigationactions comprises: blocking the request from transmittal to the originserver.
 5. The method of claim 1, further comprising: storing the one ormore request attributes of the request and the session metrics in a datastructure, wherein request attributes for subsequent requests arecompared to the request attributes in the data structure to preventsubsequent requests having similar request attributes from being sent tothe origin server.
 6. A non-transitory machine-readable storage mediumthat provides instructions that, when executed by a processor, causesaid processor to perform operations comprising: receiving a pluralityof requests from a client network application, each request in theplurality of requests for an action to be performed on a resource thatis hosted at an origin server; for each request in the plurality ofrequests, determining one or more request attributes of the request andassociating the one or more request attributes of the request with asession that identifies the client network application; computing one ormore session metrics of the session; generating a confidence value forthe client network application based at least on the determined requestattributes of the plurality of requests and the computed session metricsof the session; determining that the confidence value indicates that theclient network application is malicious; in response to determining thatthe confidence value indicates that the client network application ismalicious, performing one or more mitigation actions.
 7. Thenon-transitory machine-readable storage medium of claim 6, whereingenerating the confidence value for the client network applicationcomprises: retrieving historical request data from a data structure, thehistorical request data including previous request attributes ofprevious requests from the client network application; and analyzing theprevious request attributes of the previous requests to identifypatterns between the previous requests and the plurality of requests 8.The non-transitory machine-readable storage medium of claim 6, whereinperforming the one or more mitigation actions comprises: modifying areputation score associated with the client network application; andinitiating a challenge process in response to a subsequent request fromthe client network application.
 9. The non-transitory machine-readablestorage medium of claim 6, wherein performing the one or more mitigationactions comprises: blocking the request from transmittal to the originserver.
 10. The non-transitory machine-readable storage medium of claim6 that provides instructions that, when executed by the processor, causesaid processor to further perform operations comprising: storing the oneor more request attributes of the request and the session metrics in adata structure, wherein request attributes for subsequent requests arecompared to the request attributes in the data structure to preventsubsequent requests having similar request attributes from being sent tothe origin server.
 11. An apparatus, comprising: a processor; anon-transitory machine-readable storage medium coupled with theprocessor that stores instructions that, when executed by the processor,cause said processor to perform the following: receive a plurality ofrequests from a client network application, each request in theplurality of requests for an action to be performed on a resource thatis hosted at an origin server; for each request in the plurality ofrequests, determine one or more request attributes of the request andassociating the one or more request attributes of the request with asession that identifies the client network application; compute one ormore session metrics of the session; generate a confidence value for theclient network application based at least on the determined requestattributes of the plurality of requests and the computed session metricsof the session; determine that the confidence value indicates that theclient network application is malicious; in response to determining thatthe confidence value indicates that the client network application ismalicious, perform one or more mitigation actions.
 12. The apparatus ofclaim 11, wherein generating the confidence value for the client networkapplication comprises: retrieving historical request data from a datastructure, the historical request data including previous requestattributes of previous requests from the client network application; andanalyzing the previous request attributes of the previous requests toidentify patterns between the previous requests and the plurality ofrequests.
 13. The apparatus of claim 11, wherein performing the one ormore mitigation actions comprises: modifying a reputation scoreassociated with the client network application; and initiating achallenge process in response to a subsequent request from the clientnetwork application.
 14. The apparatus of claim 11, wherein performingthe one or more mitigation actions comprises: blocking the request fromtransmittal to the origin server.
 15. The apparatus of claim 11, whereinthe instructions further cause said processor to perform the following:store the one or more request attributes of the request and the sessionmetrics in a data structure, wherein request attributes for subsequentrequests are compared to the request attributes in the data structure toprevent subsequent requests having similar request attributes from beingsent to the origin server.